Method and system for workload management for data management systems

ABSTRACT

A system for controlling access to a downstream database management system (DMS) is provided. The system comprises an interface to maintain client connections with a plurality of upstream clients; a pooling component to establish a dynamic pool, and to selectively route each client connection to a pool; within each pool maintaining a queue comprising client database requests associated with particular client connections; and selectively granting access to the client database requests within each queue to at least one downstream DMS.

This application claims the benefit of priority to US Provisional PatentApplication No. 62,210,896 filed on Aug. 27, 2015, and entitled METHODAND SYSTEM FOR WORKLOAD MANAGEMENT FOR DATA MANAGEMENT SYSTEMS″, whichincorporated herein by reference.

FIELD

Embodiments of the present invention relate to database systems.

BACKGROUND

Database management systems may be configured to serve as multipleclient's. Each client, typically maintains a connection to a particulardatabase management system, and database requests are sent over saidconnection for processing by the database management system. Eachdatabase management system may be configured to support a maximum numberof simultaneous client connections. If the maximum number of cemeteriesclient connections is exceeded, then a request for a new clientconnection will be denied.

SUMMARY

Invention is enterprise software that manages workloads submitted byclient applications to one or more data management systems (“DMS”), suchas a relational database management system. Invention increasesscalability and availability of the data management systems by providingdetailed admission policies, scheduling primitives, and means of controlfor resource consumption.

In one embodiment, the invention can be used to achieve virtualscalability in a DMS with hard-coded limit on the number of concurrentconnections. When a large number of concurrent connection requests areattempted to DMS, the DMS might refuse accepting new connections if thenumber of already accepted connections has reached the hard-coded limit.This could result in clients unsuccessfully attempting to re-connect tothe DMS. The invention is used to virtually allow a large number ofconcurrent client connections to access the DMS, beyond what the DMStypically permits. This is enabled by pooling a large number of incomingclient connections into multiple pools, while using a smaller number ofoutgoing physical connections to actually communicate with the DMS. Eachpool has a backlog of client Requests received from different clients.After processing a given Request is complete, a Request from the backlogis granted access to the DMS. From client-side perspective, a largenumber of concurrent clients are allowed to access the DMS, while fromthe DMS perspective, the limit on the number of concurrent connectionsis still enforced even though the actual Requests might belong to anumber of clients exceeding the DMS concurrency limits.

In one embodiment, the invention can be used to achieve workloadbalancing across replicas of the same DMS. A connection pool isconfigured to route incoming traffic to a gateway replica in a clusterof replicas. The invention maintains active connections to the differentgateways representing the replicas in the cluster. When a Request isreceived, a particular replica can be chosen based on different criteriaincluding round-robin and random choice criteria. For example, if arandom choice criterion is used, a replica is chosen at random each timeto process a Request received from a given client. This achieves loadbalancing across replicas by randomly distributing the client workloadacross different DMS instances.

In one embodiment, the invention is configured to route client Requeststo different DMS replicas while adapting to workload and clientcharacteristics. For example, Requests could be routed based on clientaddress, geographical location, client priority and type of Request. Forexample, Requests in a transactional workload typically require smallprocessing times. These requests could be routed to replicas withlimited processing power. On the other hand, Requests with deepanalytical operations typically require heavy processing. There Requestsare routed to replicas with more processing power.

In one embodiment, the invention is used to achieve fault tolerance inread-only DMS replicas, when the DMS lacks fault tolerance capabilities.When a connection pool is configured to route traffic to a DMS replicain a cluster of replicas, the invention detects that the connection to aparticular replica has failed because of replica failure (e.g., diskfailure or network inaccessibility). The invention automaticallyexcludes the failed replicas from processing any further Requests. Otherconfigured replicas in the cluster are used to substitute the failedreplica. A stand-by replica could also be used to replace the failingreplica.

In one embodiment, the invention allows system administrators to monitorthe status of different connection pools and DMS gateways. This includesgetting information and aggregated statistics on the number of activeconnections, size of backlogs, long-lived client Requests, averageprocessing time in each DMS instance. Performance analysis of DMSinstances and flagging potential bottlenecks are possible based on thisinformation. For example, system administrators can detect that theaverage Request processing time of a particular DMS instance is toolarge, and hence choose to replicate the instance by adding one or moreadditional instances to achieve better load balancing and responsetimes.

In one embodiment, the invention allows system administrators to gainexclusive access to the DMS for maintenance purposes. The invention isconfigured to route all administrator Requests through a special poolwith exclusive access rights on the DMS gateway system. This guaranteesall client connections are idle for the duration of processing a givenadministrator Request. This allows maintenance and management requeststo be processed while other client requests are queued without affectingthe availability of the DMS. The clients do not lose their activeconnections to the DMS. The DMS becomes virtually available and itresponds to clients Requests as soon as the ongoing administratorRequest is complete.

Other aspects of the invention will be apparent from the detaileddescription below.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 schematically illustrates how clients typically connect to adatabase management system (DMS).

FIG. 2 shows a deployment scenario where claims connect to a DMS via anintermediate workload manager (Invention), in accordance with oneembodiment of the invention.

FIG. 3 shows a high-level block diagram of the components of theinventive workload manager, in accordance with one embodiment.

FIG. 4 shows a flowchart of how connections and establishing commandsprocessed, in accordance with one embodiment of the invention.

FIG. 5 shows a high-level block diagram of exemplary hardware that maybe used to implement workload manager, in accordance with oneembodiment.

DETAILED DESCRIPTION

In the following description, for purposes of explanation, numerousspecific details are set forth in order to provide a thoroughunderstanding of the invention. It will be apparent, however, to oneskilled in the art that the invention can be practiced without thesespecific details. In other instances, structures and devices are shownin block or flow diagram form only in order to avoid obscuring theinvention.

Reference in this specification to “one embodiment” or “an embodiment”means that a particular feature, structure, or characteristic describedin connection with the embodiment is included in at least one embodimentof the invention. The appearance of the phrase “in one embodiment” invarious places in the specification are not necessarily all referring tothe same embodiment, nor are separate or alternative embodimentsmutually exclusive of other embodiments. Moreover, various features aredescribed which may be exhibited by some embodiments and not by others.Similarly, various requirements are described which may be requirementsfor some embodiments, but not other embodiments.

Moreover, although the following description contains many specifics forthe purposes of illustration, anyone skilled in the art will appreciatethat many variations and/or alterations to the details are within thescope of the present invention. Similarly, although many of the featuresof the present invention are described in terms of each other, or inconjunction with each other, one skilled in the art will appreciate thatmany of these features can be provided independently of other features.

Accordingly, this description of the invention is set forth without anyloss of generality to, and without imposing limitations upon, theinvention.

Broadly, embodiments of the present invention disclose techniques andsystems controlling access to database management system (DMS).

Before describing the invention, it may be useful to review some basicconcepts around the deployment of applications and data managementsystems as outlined in FIG. 1 .

A client application (“Client”) (110) establishes one or moreconnections with DMS (140) and communicates a workload consisting ofcommands (“Request”) to DMS, then receives data messages (“Result”) thatit process. After processing of the workload is complete, the clientshuts down the connection. Depending on the application logic, theworkload can be an individual command or, more typically, a sequence ofcommands. If the workload consists of multiple commands, the session isconsidered “idle” between the time results for one command are returnedand a new request is submitted.

The establishing of a connection as well as the subsequent communicationmay be conducted using connector libraries typically provided by thevendor of DMS or third parties. Typical, embodiments of such connectorsare OBDC or JDBC libraries.

In the following, the term “Client” is used in a generic way toencompass a wide variety of different client applications; clientapplications may differ in workloads submitted, results consumed, etc.

In the section “Application Scenarios” a variety of problems arisingfrom this way of deploying Client and DMS are illustrated in detail.

In contrast, FIG. 2 depicts a deployment of DMS and instances of Clientusing the invention. Instances of Client (210) now connect to theInvention (220) instead of DMS (240), and Invention connects to DMS.Invention manages connection and workload requests as detailed below.Section “Application Scenarios” illustrates various use cases and theirbenefits.

FIG. 3 is a diagram illustrating an embodiment of Invention (300). Itconsists of the following components. Network Listener (302) thataccepts incoming connection requests using standard network protocols,such as TCP/IP. Network Listener routes the connection to a module(“Admission Control”) (304) that selects and applies a policy(“Admission Policy”) (306) to determine (i) the method of authenticationused for the connection, and (ii) the resource pool (“Pool”) and gateway(“Gateway”) to be used in routing the connection.

Admission Policy is selected based on a number of criteria (306) thatmay include any of the following: (i) identity of user of incomingrequest, i.e., login; (ii) database or data container Client wants toconnect to; (iii) IP address where connection request was originatedfrom, including masking of the IP address to consider only parts of theaddress; (iv) name of the application; variety of other criteria basedon parameters transmitted at the time of the connection request may beused to select Admission Policy.

The validity of Admission Policy can be either general, i.e., alwaysvalid, or limited by ranges or patterns of dates and/or times.

Admission Control may be configured to perform authentication, including(i) authentication via locally stored passwords using standardencryption such as SHA-1, MD5, etc., (ii) integrated security in theform of LDAP (390), including Active Directory, or (iii) Single-Sign On(392) using Kerberos or (iv) other standard authentication protocols.

Invention manages one, or more typically, a multitude of pools (308).Pool controls the number of concurrent connections from Invention to DMSas well as the traffic transmitted over these connections at any giventime. Routing incoming connections to different pools effectivelydivvies up DMS's resource bandwidth between different groups ofconnections, establishes priorities between different instances ofClient, and accomplishes scalability, availability and trafficoptimization objectives as detailed in “Application Scenarios” below.Pool also controls life-cycle management of connections through timeoutsconcerning idle sessions and active transactions, see Workflow detailsbelow.

Pool is characterized by (i) the number of concurrent connections aninstance of Pool permits to DMS (“Capacity”), (ii) number ofconcurrently active statements (“Active Slots”), usually significantlylower than Capacity, and (iii) number of connection requests that arewaitlisted (“Backlog”).

Pool routes the connection request and subsequent commands to Gateway(310) that specifies the connection parameters for the connection to theDMS.

Control Module (318) provides a means to administrators to affect Poolor Connection via language extensions (“Control Language”) to terminate,pause, and activate Connection or Pool. Control Language contains alsolanguage primitives for modifying any configuration detail in the systemincluding configuration details of Pool, number and configurationdetails of Policy, number and configuration details of Gateway, etc.

Tracing facility (320) monitors Connection and makes detailedobservations available for external consumption via files (322), HTMLover HTTP (324) or other formats. Observations include timing ofindividual steps of progress of Connection such as time when request wasreceived, time spent waiting for admission to Pool, full transcript ofRequest, time Request was submitted to DMS, time when first data ofResult was received, time Request was completed successfully, or errorreceived, etc.

Lock Manager (320) provides means to acquire shared/exclusive locks onany resource in Invention, including locks for mutually exclusive orshared access (“Access Lock”) to DMS gateways (326), see below fordetails.

Detailed Control Flow

The following describes how connections are established and commands areprocessed as detailed in flowchart in FIG. 4 .

Invention accepts incoming connection request (402) via standard networkprotocol such as TCP/IP using Network Listener (302). If client requestsconnection to be encrypted (404), Connection is upgraded (406) using anystandard encryption technology such as Transport Layer Security (TLS) orSecure Sockets Layer (SSL).

Connection is then matched against available policies (408) using avariety of criteria as discussed above. Policies are matched in priorityorder as defined by the administrator. The first matching policy(“Policy”) is used. If no policy matches the search criteria (410) anerror message is returned to the client and the connection is terminated(480).

Based on Policy, an authentication method is determined and Client iseither directly authenticated or, in case of pass-throughauthentication, authentication is deferred to DMS once connection isestablished (412). If immediate authentication is required according toPolicy but does not succeed (414), an appropriate error message isreturned to Client and Connection is terminated (480).

Otherwise, Policy determines Pool through which all communication willbe conducted (416). If Pool is closed, i.e., does not accept newconnections at this time (418) Connection is held in waiting patternuntil Pool is activated again (420). If the limit on Backlog, asconfigured by administrator, is reached (422) appropriate error messageis returned to Client and Connection is terminated (480).

Otherwise, Connection waits for Active Slot to become available (424).Connection waits for first request from Client or timeout to occur(426). If timeout occurred (428), appropriate error message is returnedto Client and Connection is terminated (480).

Otherwise, Access Lock is acquired (430). Once granted, Request istransmitted to DMS via Gateway (Y32). If Request is a request toterminate Connection (434), indicating the end of the workload,Connection is shut down and workflow terminates.

Otherwise, Connection waits for Result and forwards it on to Client(436). If Result is not completely received within a configured timeout(438), appropriate error message is returned to Client and Connection isterminated (480).

Otherwise, if Connection is idle (440), i.e., no transactions arepending, Access Lock is released (444) and control flow continues withwaiting for client requests (426).

If Connection is not idle (440), Access Lock remains held and Connectionwaits for next request from Client (442). If timeout occurred,appropriate error message is returned to Client and Connection isterminated (480). Otherwise, control flow continues at (432).

Instead of terminating the connection from Invention to DMS, Inventionmay retain unused connections and re-use them later in order to avoid apotential time penalty for establishing and destroying of connections toDMS.

Application Scenarios

The following are detailed descriptions of application scenarios thatexemplify how an embodiment of the invention can be used. The scenariosare chosen to each illustrate a specific scenario. In practice thescenarios presented will widely overlap.

Scenario 1: Scalable Connection Management

Typically, a multitude of clients may connect simultaneously to DMS. AsDMS has only limited resources such as memory, CPU capacity, I/Obandwidth, etc. the system's performance declines with increasing numberof simultaneous connections. Depending on the types of requests, i.e.,the workloads of individual clients, the DMS's resources may getdepleted to the point where new connections cannot be made and existingworkloads cannot finish or finish within reasonable time. In thissituation, the system is considered unavailable or “down” with severeramifications for the users: applications are denied access and businessprocesses are disrupted, existing connections to the database may getstarved of resources and prevented from making any progress, and even arestart of the entire DMS may be needed, requiring significantintervention from IT staff. Typically, the maximum number of connectionspresents a hard limit that is configured at system start in DMS. It isgenerally desirable to keep the limit on concurrent connectionslow—typically in the low hundreds—to avoid wasting resources such asmemory unnecessarily and take into account limitation of the system'sscalability. Depending on the characteristics of the workloads it may bedesirable to have no more than a fraction of the connections submitconcurrently requests to be processed in parallel. As the number ofconnections cannot be controlled by the DMS or operators of the DMS butdepends solely on the number of clients or applications the lack ofcontrol and the prospect of system failures in case of overload renderthe DMS as unstable or lacking in robustness.

Using Invention makes operating applications and DMS scalable and safeas follows. The maximum number of connections DMS is configured tohandle is not reached nor can it be exceeded. Even when a large numberof connection attempts are submitted to Invention no connections arerefused and processing in Client is not interrupted or disturbed. Thenumber of truly concurrently submitted requests is controlled by thecapacity of Access Lock. This gives administrators fine-grain controlover the degree of actual concurrency of processing in DMS, yet, makesDMS appear scalable and available at any point in time.

Scenario 2: Virtual Single-User Mode for Maintenance Operations

A number of maintenance operations in DMS require that no instance ofClient is performing concurrent operations, i.e., all connections beidle. This is typically accomplished by shutting down DMS and restartingit in a restricted mode that allows only a single user to connect. Thismakes DMS only accessible to the administrator to perform themaintenance operation. Once the operation is complete, DMS is shut downagain and restarted in regular multi-user mode.

By configuring (i) a pool through which administrator connections arerouted and (ii) Access Lock to offer exclusive access for this pool,Invention implements a admission control mechanism, that enablesadministrator to gain exclusive access with the guarantee that anyconcurrent connection is idle for the duration of any operationsubmitted via the administrator pool (“Virtual Single-user Mode”). As aresult, the management operations can be executed, even though theyrequire restricted access, without compromising the overall availabilityof the system or causing disruption to clients and business processes.

Scenario 3: Tracing and Auditing

Pool may be configured to retain detailed information about timing ofevent at a finer resolution than workload, i.e., times of individualmessages being exchanged between Client and DMS. Timing andauthentication information is made available for external consumptionthrough files or API's such as HTTP. The information logged can serve asaudit information detailing exact information about the requester andnature and content of individual requests. Another use case for theinformation is detailed analysis of the performance characteristics ofDMS typically used for trouble-shooting and sizing and capacity planningof DMS. Timing information includes time of arrival of requests,identity of application or user, content of request, time request isqueued in Invention, time request is submitted to DMS, time firstresults are obtained, time request is complete or encountered errorcondition, etc.

Scenario 4: Multi-DMS Routing and Load-Balancing

It is often desirable to route connections to different copies of DMSfor purposes of load-balancing or isolating of workloads. Pool can beconfigured to route connections to different gateways based on amultitude of criteria such as round-robin or based on load profiles ofindividual DMS instances. Typical configurations include routing of allwrite access to one instance and routing of all read-only access acrossa cluster of replicas.

To enhance understanding of the present invention, consider the exampleof an insurance company operating globally that maintains insurance andclaims data in a DMS. The data is accessed by a large number of clientapplications across all departments. During a typical business day,claims data is reported by field agents, rates and pricing is requestedby sales representatives, and regulatory reporting is performed at theend of the business day. Clients' interaction with the DMS is executedthrough applications that connect to the DMS, run on or more databasequeries or update existing records, then terminate the connection. Atypical connection may last anywhere from seconds to hours, the actualqueries or commands are usually in the order of seconds. In addition, avariety of user groups such as executives that access the DMSoccasionally—but at high priority—during planning or board meetingsexist across the enterprise. For the above example, the following usecases may be realized:

1. Traffic Management

-   -   The DMS is provisioned to accommodate a certain capacity of        concurrent connections, e.g., 200 connections. However, during a        surge pattern such as a natural disaster, the number of requests        to file claims and/or check insurance policies may exceed        regular traffic by a multiple. As a result, client applications        may crash or error out and show behavior similar to that of an        overloaded wireless telephone network: repeated connection        attempts only increases the contention on the DMS but actual        throughput is often diminished. In extreme cases, the DMS my run        out of resources and shut down completely leading to        catastrophic results at the business level.    -   Using Invention, incoming connection request are queued until        capacity on the DMS frees up and first-come-first-served order        is preserved. Applications do not crash or error out, instead        may experience short delays but are fully functional.

2. Priority Routing

-   -   During certain days of the week as well as certain times of the        day, overall workload may be heavier than at other times leading        to generally slower response times.    -   Using Invention groups of applications or users can be assigned        different priorities, e.g., connection requests by executives        can be given priority over other requests.

3. Load-Balancing

-   -   To overcome throughput limitations of a DMS, multiple replicas        with identical data loaded may be used. Invention can        load-balance between the different systems according to        different policies including round-robin where the next incoming        connection is assigned to the next DMS according to a predefined        sequence, or uniform balancing where connections are assigned a        DMS chosen randomly. Round-robin is generally considered a fair        scheduling tactic, however, uniform distribution may outperform        round-robin as it is not susceptible to accidental traffic        patterns that might end up taxing one instance harder than        others.

4. Data Sharding—Access Policy

-   -   In many areas of business, including the insurance business,        regulation requires certain information to be retained within        the country of business, e.g., data about insurance policies        sold in Germany must not be stored or processed outside of        Germany. Therefore, the company must maintain data centers with        separate DMS's for different geographies. Invention may be        configured to route connections according to their country of        origin to the appropriate DMS. This simplifies the setup of the        client applications and avoids that clients accidentally, or        willfully, access data that is outside of the corresponding        jurisdiction.

5. Data Sharding—Performance Optimization

-   -   For an additional scenario for sharding consider departmental        policies where certain user groups have different performance        requirements when accessing data. For example, insurance agents        who access the DMS concurrently need up-to-date pricing to        present customers with appropriate quotes. End of day reporting        for regulatory purposes, however, requires consolidated data and        is accessed only by a few controllers. This presents an cost        optimization opportunity for IT: by using Invention, agents'        request can be routed to a high-performance/high-throughput        instance of DMS, whereas end-of-day reporting is routed to a        much more cost-effective replica of the DMS.

6. Operations and Maintenance

-   -   Occasionally, the DMS may need to be taken off-line for        emergency maintenance such as replacement of hardware, restart        after power failure, etc. Some of these operations require that        no user connections are currently active on the DMS, others may        require complete shutdown and restart of the DMS. Invention        enables queuing and buffering of incoming request so DMS can be        taken off-line, maintained, and restarted without affecting        users' applications. Even complete shutdown and restart of the        underlying DMS which may take 10's of seconds does not result in        interruptions of clients' connections.

Besides operational benefits such as enhanced throughput or up-time,Invention's benefits extend also to the client applications: UsingInvention, a single-system view is preserved, i.e., client applicationsare unaware of the different underlying systems but connect to only onecentral point that is Invention. The benefit of a single-system view isthe decoupling of front-office, i.e., client applications andback-office, i.e., IT department: the additional flexibility allows bothsides to deploy software more flexibly because changes on either side donot require re-wiring/re-configuration of systems but are mitigated andoptimized by Invention.

Invention can be used to supplement an existing DMS with workloadmanagement and extends workload management capability across multipleinstances of a DMS. Invention enhances the scalability of a DMS often bya significant multiple of what DMS provides natively. By boosting theavailability of DMS through Virtual Single-user Mode or temporaryclosure of pools, DMS—which would otherwise not be considered highlyavailable—can now be used in mission-critical application scenarios. Inaddition, Invention provides a wide array of utilities and mechanisms tosimplify deployment of applications and DMS by (i) giving administratorsbetter visibility into traffic and traffic patterns between Client andDMS, and (ii) providing controls that put administrators in charge.

FIG. 5 shows an example of hardware 800 that may be used to implementInvention, in accordance with one embodiment. The hardware 500 mayinclude at least one processor 502 coupled to a memory 504. Theprocessor 502 may represent one or more processors (e.g.,microprocessors), and the memory 504 may represent random access memory(RAM) devices comprising a main storage of the hardware, as well as anysupplemental levels of memory e.g., cache memories, non-volatile orback-up memories (e.g. programmable or flash memories), read-onlymemories, etc. In addition, the memory 504 may be considered to includememory storage physically located elsewhere in the hardware, e.g. anycache memory in the processor 502, as well as any storage capacity usedas a virtual memory, e.g., as stored on a mass storage device.

The hardware also typically receives a number of inputs and outputs forcommunicating information externally. For interface with a user oroperator, the hardware may include one or more user input devices 506(e.g., a keyboard, mouse, etc.) and a display 508. For additionalstorage, the hardware 800 may also include one or more mass storagedevices 510, e.g., a Universal Serial Bus (USB) or other removable diskdrive, a hard disk drive, a Direct Access Storage Device (DASD), anoptical drive (e.g. a Compact Disk (CD) drive, a Digital Versatile Disk(DVD) drive, etc.) and/or a USB drive, among others. Furthermore, thehardware may include an interface with one or more networks 512 (e.g., alocal area network (LAN), a wide area network (WAN), a wireless network,and/or the Internet among others) to permit the communication ofinformation with other computers coupled to the networks. It should beappreciated that the hardware typically includes suitable analog and/ordigital interfaces between the processor 712 and each of the components,as is well known in the art.

The hardware 500 operates under the control of an operating system 514,and executes application software 816 which includes various computersoftware applications, components, programs, objects, modules, etc. toperform the techniques described above.

In general, the routines executed to implement the embodiments ofInvention, may be implemented as part of an operating system or aspecific application, component, program, object, module or sequence ofinstructions referred to as “computer programs.” The computer programstypically comprise one or more instructions set at various times invarious memory and storage devices in a computer, and that, when readand executed by one or more processors in a computer, cause the computerto perform operations necessary to execute elements involving thevarious aspects of the invention. Moreover, while the invention has beendescribed in the context of fully functioning computers and computersystems, those skilled in the art will appreciate that the variousembodiments of the invention are capable of being distributed as aprogram product in a variety of forms, and that the invention appliesequally regardless of the particular type of machine orcomputer-readable media used to actually effect the distribution.Examples of computer-readable media include but are not limited torecordable type media such as volatile and non-volatile memory devices,USB and other removable media, hard disk drives, optical disks (e.g.,Compact Disk Read-Only Memory (CD ROMS), Digital Versatile Disks,(DVDs), etc.), flash drives among others.

Although the present invention has been described with reference tospecific exemplary embodiments, it will be evident that the variousmodification and changes can be made to these embodiments withoutdeparting from the broader spirit of the invention. Accordingly, thespecification and drawings are to be regarded in an illustrative senserather than in a restrictive sense.

1. A system for controlling access to a downstream database managementsystem (DMS), the system comprising: an interface to maintain clientconnections with a plurality of upstream clients; a pooling component toestablish a dynamic pool, and to selectively route each clientconnection to a pool; within each pool maintaining a queue comprisingclient database requests associated with particular client connections;and selectively granting access to the client database requests withineach queue to at least one downstream DMS.
 2. The system of claim 1,wherein the pooling component routes each client connection based on apolicy.
 3. The system of claim 1, wherein each dynamic pool compriseslimits a number of concurrent connections permitted to the DMS.
 4. Thesystem of claim 1, wherein each dynamic pool limits a number ofconcurrent active slots for each pool.
 5. The system of claim 1, whereineach dynamic pool limits a number of connection requests that can bewaitlisted within the queue.
 6. The system of claim 1, furthercomprising a control module configured to allow administrators toconfigure each pool.
 7. The system of claim 1, further comprising atracing component to monitor aspects of a connection.
 8. The system ofclaim 7, wherein said aspects comprises a time when a request wasreceived, time spent waiting for admission to a pool, a transcript ofthe request, a Time when first data pursuant to the client databaserequest is received, and a time when a client database request iscompleted.
 9. The system of claim 1, configured to selectively grantaccess to said upstream clients to a plurality of downstream DMSinstances.
 10. The system of claim 9, wherein said downstream DMS definea cluster within which the particular instances are replicas of eachother, save for variations due to data commit operations
 11. The systemof claim 1, configured to execute a work load balancing process toselect a DMS the particular instance to process a claim to this requestbased on a workload balancing criterion.
 12. The system of claim 11,wherein said working balancing criterion comprises a criterion torandomly select said instance.
 13. The system of claim 11, wherein saidwork load balancing criterion comprises a criterion to select saidinstance on a round robin basis.
 14. The system of claim 11, whereinsaid work load balancing process is configured to select said instancebased on factors selected from the group consisting of client address,geographical location, client priority, and a type associated with theclient database request.
 15. The system of claim 10, further comprisinga mechanism to detect an operational state associated with each DMSreplica.
 16. The system of claim 15, configured to exclude anynon-operational DMS replicas from said work load balancing process. 17.The system of claim 10, further comprising a special pool configured toqueue client database requests during maintenance operations.